The Very Best of Atari Inside/The Very Best of Atari Inside 1.iso/mint/mfs055/minit.doc

Text File | 1991-11-29 | 8KB | 113 lines

Minit is a minix filesystem initialiser. It behaves like a very cut down
version of 'mkfs'. A TOS disk or hard drive partition can be turned into
a minix partition or disk simply by doing a 'minit A:' or whatever drive
you want the filesystem on. NB THIS WILL TOTALLY AND IRRETRIEVABLY WIPE
THE DRIVE YOU SELECT. If you want to experiment try it on floppies before
comitting your hard disk.

    This is all very well , however if you try to access a minix
partition without MiNT or minix.xfs present then TOS will quite happily
write all over it and probably trash it. There are two ways round this and
that is what the -Z and -P options are for. With neither of these options
the filesystem looks like a TOS filesystem to GEMDOS and can be trashed.
With the -Z option several BPB entries are zeroed which confuses GEMDOS and
makes it leave the filesystem alone. Actually some versions of GEMDOS will
lock up when they meet such a disk , however this is what mkfs under Minix
itself does. Unfortunately some versions of hard disk driver software will
refuse to access such a partition making minix.xfs unable to access the
partition and worse still making it impossible for most disk editors to
alter it either !! You should be OK with floppies and -Z though. The -P
option is a bit more subtle, it makes the disk look like a valid TOS
partition with a full root directory , any attempt to write to the drive
fails because it can't create a new filename, also the name 'MINIXFS' is
shown when checking the volume name of the drive in question under GEMDOS
(i.e. no minix.xfs running), this should make it impossible for GEMDOS to
normally write to the partition, but since it looks like a TOS partition
all driver software should be happy. For this reason the '-P' option is
recommended unless you are sure your driver software will tolerate '-Z'
(ICD software does , AHDI does NOT ). If you want to change an already existing
filesystem to this '-P' form use the '-p' option , this shouldn't harm an
already existing Minix partition or a TOS one (which it will refuse to change)
but just in case it still puts up the warning and requires confirmation.

    A question which arises is: how do you get minix.xfs to read an already
existing minix partition if your driver software doesn't like the zeroed
BPB which is the default for Minix mkfs? Currently you have two options ,
borrow some other driver software that works in your setup and do a
'minit -p' on the unreadable partitions, or compile the 'fixup.c' program
provided under Minix , then simply do a 'fixup /dev/hd2' or whatever under
Minix. Note also that the method used in '-P' will only work with 512 byte
sectors , you can force 'fixup' to change the sector size for you but this
means that the 'auto' value for 'minit' will no longer work and you will
need to pass the number of blocks in the filesystem manually to minit with
the '-b' option, if you should want to reinitialise the partition with minit.
Currently 'minit' will refuse the '-P' or '-p' options on partitions which
don't have 512 byte sectors.

    One potential snag with all methods is if you use a very early version
of 'mkfs' under minix. Version 1.1 zeroed the whole boot sector of the minix
partition. This is very bad news indeed , and will probably make such a minix
partition inaccessbile to *any* driver software. The best thing to do is to
restore the partition to TOS (if your hard disk software allows you to restore
single partitions) and use 'minit -P' to initialise the partition , then
restore the partition from backup , alternatively you could use a later mkfs
followed by the 'fixup' program supplied. A quick and dirty solution is to copy
the boot sector from another TOS partition , preferably one the same size ,
under minix a suitable command to do this is :
dd if=/dev/hd1 of=/dev/hd3 count=1
where 'hd1' is the TOS partition and 'hd3' is the (unreadable) minix partition,
then if your driver will tolerate the partitions now (and if it wont please
let me know), do a minit -p on the relevant partitions , or fixup if you prefer,
so that the partitons are protected.

    The '-V' option creates a V2 filesystem , this is the new alternative
Minix filesystem format which has a couple of advantages over the old one.
If you have Minix you will need to patch it up to 1.6xxxx to recognise V2.
First it supports the atime,mtime,ctime fields whereas the old V1 system only
supports mtime. Also it uses longs for block references, this theoretically
makes it possible to have *very* large filesystems without the need to bump
up the sector size in the manner AHDI has to with BGM partitions. There is a
snag however , many kinds of partitioning software will not permit you to
have very big partitions without a large sector size , what you do here depends
on the driver software , you could try modifying the sector size in the boot
sector of such a partition. However there is no way for 'minit' to recognise
the size of huge partitions so you will have to manually pass the number of
blocks to 'minit' with the '-b' option. Also your driver software must support
the 'extended Rwabs' system call to work properly under such circumstances,
AHDI 3.1 and later does and later ICD software also does , if in doubt try the
'-t' option with 'minit' on an arbitrary GEM partition of your hard disk ,
this just checks for the 'extended Rwabs' by saying if the extra 'Lrecno'
parameter is present or not. If 'Lrecno' is not supported you can't use huge
filesystems , try with a newer version of the disk software.

    minix.xfs version 0.52 and later supports V2 filesystems . Note
however that I don't have the facilities to check large filesystems and
mine are all < 16 Mb so this facility is entirely untested. I would be
very grateful if someone would try making large V2 filesystems and filling
them up to see if minix.xfs copes OK.

    Finally the '-n' option. This is a bit experimental at present.
Quite often filenames get truncated so that 14 characters mixed case isn't
enough. So what I've done is to increase the directory entry size and make
version 0.53 and above of the filesystem automatically sense it and act
accordingly. What this means is that if you use the '-n' option then the
maximum filename size increases from 14 to 16*d-2, where 'd' is the number
following the '-n' option. d must be a power of two and lie between 1 and
16 (inclusive). 1 is normal and is the default. With 2 you get 30 character
filenames which should be enough for most applications. When minix.xfs
is compiled the option MAX_INCREMENT specifies the largest value for the
increment (that is the number following '-n' to minit) that can be handled.
You should note that TOS specifies a maximum path name length of about 128
characters (64 for early versions of TOS) and so programs may well expect
pathnames to be smaller than this . As a result making the increment bigger
than say 4 is not a good idea.

NBB Minix itself does ***NOT*** recognise these larger filename filesystems
and will be very confused by them. It may be possible to persuade Minix to
tolerate bigger filenames by altering the relevant parameters in the directory
structure and recompiling everything in sight (libraries , fs , kernel , mm and
all the tools). However this will then mean it wont handle  the original
filesystem type and be confused by that ... However you could just recompile
a few useful tools like fsck to repair the long filename filesystems. Note,
at this time I haven't tried this !